1. Technical Field
The invention relates to cryptography. More particularly, the invention relates to a mechanism for validating an application image as it is installed on a system with respect to the binding of the application to a certificate, as well as validating the system service element upon which the application image is installed.
2. Description of the Prior Art
Customers of large computer systems are typically multinational corporations that want to purchase enterprise wide computer based solutions. The distributed nature of such organizations requires them to use public international communications services to transport data throughout their organization. Naturally, they are concerned about the security of their communications and seek to use modern end-to-end cryptographic facilities to assure privacy and data integrity.
The use of cryptography in communications is governed by national policy and unfortunately, national policies differ with respect to such use. Each national policy is developed independently, generally with a more national emphasis rather than international considerations. There are standards groups that are seeking to develop a common cryptographic algorithm suitable for international cryptography. However, the issue of international cryptographic standards is not a technical problem, but rather it is a political issue that has national sovereignty at its heart. As such, it is not realistic to expect the different national cryptography policies to come into alignment by a technical standardization process.
The issue of national interests in cryptography is a particular concern of companies that manufacture open-standards-based information technology products for a worldwide market. The market expects these products to be secure. Yet, more and more consumers of these products are themselves multinational and look to the manufacturers to help them resolve the international cryptography issues inhibiting their worldwide information technology development. The persistence of unresolved differences and export restrictions in national cryptography policies has an adverse impact on international market growth for secure open computing products. Thus, it would be helpful to provide an international framework that provides global information technology products featuring common security elements, while respecting the independent development of national cryptography policies.
Nations have reasons for adopting policies that govern cryptography. Often these reasons have to do with law enforcement and national security issues. Within each country there can be debates between the government and the people as to the rightness and acceptability of these policies. Rather than engage in these debates or try to forecast their outcome, it is more practical to accept the sovereign right of each nation to establish an independent policy governing cryptography in communication.
Policies governing national cryptography not only express the will of the people and government, but also embrace certain technologies that facilitate cryptography. Technology choice is certainly one area where standardization can play a role. However, as indicated earlier this is not solely a technical problem, such that selection of common cryptographic technologies alone can not resolve the national policy differences.
A four-part technology framework that supports international cryptography, which includes a national flag card, a cryptographic unit, a host system, and a network security server is disclosed by K. Klemba, R. Merckling, International Cryptography Framework, in a copending U.S. patent application Ser. No. 08/401,588, which was filed on Mar. 8, 1995, now U.S. Pat. No. 5,651,068.
The framework supports the design, implementation, and operational elements of any and all national policies, while unifying the design, development, and operation of independent national security policies. The framework thus gives standard form to the service elements of national security policies, where such service elements include such things as hardware form factors, communication protocols, and on-line and off-line data definitions.
FIG. 1 is a block diagram of the international cryptography framework 10, including a national flag card 12, a cryptographic unit 14, a host system 16, and a network Security server 18. Three of the four service elements have a fundamentally hierarchical relationship. The National Flag Card (NFC) is installed into the Cryptographic Unit (CU) which, in turn, is installed into a Host System (HS). Cryptographic functions on the Host System cannot be executed without a Cryptographic Unit, which itself requires the presence of a valid National Flag Card before it's services are available. The fourth service element, a Network Security Server (NSS), provides a range of different security services including verification of the other three service elements, and thus acts as a trusted third party.
FIG. 2 is a perspective view showing the four basic elements of the framework, including the cryptographic unit 14 and several national flag cards 12, a host system 16, and a national security server 18. In the following sections each service element is discussed in greater detail.
NATIONAL FLAG CARD (NFC). The NFC 12 is a small stamp sized (25.times.15 mm) ISO 7816-type smart card, i.e. a one chip computer 26 having a non-volatile memory. The NFC is mounted on a rigid substrate and sealed in a tamper-proof package. The NFC is typically produced independently and distributed by National agencies (e.g. United States Postal Service, German Bundespost). National agencies may also license NFC production and distribution to private industry.
The action of the NFC service element is to enforce a nation's policy governing the use of cryptography. An NFC is a complete computer that can be constructed as a multi-chip architecture to include custom integrated circuits. It also would include tamper resistance and unique identification features, making unauthorized entry or duplication impossible. For example, the NFC could be sealed in such a way that opening its package would destroy any integrated circuit or data inside. The NFC could require receipt of an encrypted authorization issued by the National Security Server. All services of the NFC are provided via standard ISO 7816 message exchanged protocol between the NFC and other service elements. This format is identical to the smart card used in Europe to support GSM in cellular voice services.
CRYPTOGRAPHIC UNIT (CU). The cryptographic unit is a tamper-resistant hardware component designed to provide protected cryptographic services under the strict control of an NFC. Cryptographic units would be produced competitively by system vendors and third parties and be free of import and export restrictions. Because the cryptographic unit includes critical elements of security such as encryption algorithms and keys, it is likely that it would be certified (e.g. NIST, NCSC, or ITSEC Certified) for customer assurance. It is a feature of this embodiment of the invention that the cryptographic unit does not contain any governing policy other than its dependence upon a NFC. This component is preferably designed for performance and protection with customization for a given Host System.
HOST SYSTEM (HS). The HS is identifiable as the hardware component that delivers secure information technology services directly to the user. HSs are typically a general purpose information technology device and would be produced competitively in a wide open market. Examples include personal digital assistants, personal computers, workstations, laptops, palmtops, networked servers, main frames, network printers, or video display units, as well as embedded systems for control and measurement. The function of the HS service element in the framework is to provide an Application Programming Interface (API) for accessing the cryptographic unit service element. Preferably, cryptographic unit support is provided as an option available on the HS.
NETWORK SECURITY SERVER (NSS). The NSS is a network node designed and designated to provide trusted third party Security services. For example, any network access, such as via modems 30, 32 over a network 34, must be authenticated by the NSS. In the context of national security, NSSs are preferably developed, owned, and operated by government agencies. Some of the functions provided by the NSS service element include service element authentication, message stamp authentication, national policy enforcement, and cryptographic key distribution. The importance of the NSS can rise sharply in environments where a strong degree of verification is prerequisite to cryptographic use. The NSS also plays a significant role in the interoperability of differing National cryptographic policies.
Scope Of The Framework. The scope of the framework is largely defined by the scope of the NFCs. The basic scope of the NFCs is that of a domain. A domain can be as large as worldwide and as small as a business unit. At the domain level there is no unique distinction among its members. While this framework primarily focuses on national and international domains (e.g. France, Germany, United States, United Kingdom, European Commission, NATO, North America, G7) other domains or sub-domains are also considered. For example, industry domains (e.g. Telecom, Healthcare, Financial Services, Travel), corporate domains (e.g. Hewlett-Packard, Ford Motor Company, CitiBank), association domains (e.g. IEEE, ISO, X/Open), service domains (e.g. Compuserve, America On-Line), and product domains (e.g. Lotus, Microsoft, General Motors, Proctor & Gamble).
Beyond domains and subdomains the scope of the framework can optionally be expanded to define uniqueness within a domain. Again it is the NFCs that make this narrower scope possible. Providing uniqueness means allowing for the transfer of unique or personal data to be transferred to the NFC either at the time of purchase or at the point of initial validation. NFCs are considered anonymous when dealing at the domain level. When uniqueness is added, NFCs are no longer anonymous.
Interconnect Of Framework Elements. The interconnection of service elements (e.g. NFC, CRYPTOGRAPHIC UNIT, HS, NSS) of this framework is accomplished by the adoption of standard Application Programming Interfaces (e.g. X/Open, OSF) and industry standard protocol exchanges (e.g. TCP/IP, ISO, DCE, X.509). The interconnection of elements may be synchronous (i.e. on-line), asynchronous (i.e. off-line), local (e.g. runtime library), remote (e.g. RPC) or any combination of these. For example, a policy that involves personalization of NFCs could perform a one time authorization function via a NSS making it unnecessary for future on-line verification with an NSS until the NFC expires.
Beyond the physical interconnection of the framework's service elements lies the message exchange between the elements and the actual services provided and requested via this message exchange. FIG. 3 illustrates the message exchange paths, between an NFC 12 and a cryptographic unit 14 (path 35), between the cryptographic unit 14 and an HS 16 (path 36), and between the HS 16 and an NSS 18 (path 37). A virtual connection 38 exists between the NFC and the NSS. Messaging protocol between the HS and the cryptographic unit along the path 36 are best taken from cryptographic API standardization efforts (e.g. NSAs Cryptographic API, Microsoft's Cryptographic API). The messaging protocol between the cryptographic unit and the NFC along the path 35 is categorized into two groups: initialization protocols, and operational protocols. The initialization protocols must be successful before operational protocols are active.
Consequently, it would be useful to provide a common, accepted cryptography framework, wherein independent technology and policy choices can be made in a way that still enables international cryptographic communications consistent with these policies. Critical to the implementation of the framework is the provision of a fundamental technology that allows the production of the various service elements. While various implementations of the service elements are within the skill of those versed in the relevant art, there exists a need for specific improvements to the state of the art if the full potential of the framework is to be realized.
For example, it would be advantageous to include within the framework a system the establishes that an application is a legitimate application having authorization for a requested class of service. It would also be advantageous for the application to verify that the service element is a legitimate recipient of the application image and service requests. It would additionally be advantageous if such system operated in accordance with a Security paradigm that required at least a tamper proof transport mechanism, such as a certificate, and a mechanism for establishing and maintaining continuity during a particular transaction.